Extends the existing VDDK + virt-v2v VMware-to-KVM import path so the
converted disk can be written straight into an RBD pool as a raw image,
with in-place virt-v2v finalization. Adds host-capability detection for
qemu-img RBD support, RBD qemu copy, virt-v2v in-place, and direct RBD
import, advertised via ReadyCommand and reconciled by the agent manager.

Signed-off-by: Andrija Panic <andrija.panic@gmail.com>

Extends the KVM unmanaged import / manage-volume flow so an existing raw
RBD image can be adopted directly as a VM root volume, including the
RBD-format check in the volume orchestrator and the libvirt volume
inspection path.

Signed-off-by: Andrija Panic <andrija.panic@gmail.com>

Unifies the host-capability keys that the CBT warm-migration and VDDK
direct-RBD-import features introduced independently under different
names, using feature-neutral names that describe what is probed:
  host.vmware.cbt.support                     -> host.vddk.blockcopy.support
  host.vmware.cbt.in.place.finalization.support -> host.vddk.blockcopy.inplace.finalization.support
  host.vmware.cbt.rbd.support                 -> host.vddk.blockcopy.rbd.support
  host.qemu.img.rbd.support                   -> host.qemu.rbd.support
  host.virt.v2v.inplace.support / host.virtv2v.in.place.version -> host.virtv2v.inplace.*
Drops the redundant host.rbd.qemu.copy.support alias (identical to
host.qemu.rbd.support) and its hostSupportsRbdQemuCopy() delegate.

Signed-off-by: Andrija Panic <andrija.panic@gmail.com>

docs/vmware-cbt/architecture.md and docs/vmware-cbt/README.md were added
without the Apache license header, which failed the RAT license check and the
pre-commit insert-license hook. Add the standard ASF header (identical to the
one already present in docs/vmware-cbt-migration.md).

Signed-off-by: Andrija Panic <andrija.panic@gmail.com>

…ey names

State Apache CloudStack 4.24.0.0 as the target release (schema delivered via the
4.24.0.0 upgrade path, with a note that the DDL currently rides in
schema-42210to42300.sql pending the main version bump), and replace the
pre-consolidation host-capability key names with the current
host.vddk.blockcopy.* / host.virtv2v.inplace.version names.

Signed-off-by: Andrija Panic <andrija.panic@gmail.com>

Staged VMware-to-KVM imports (virt-v2v conversion to an NFS temporary
location followed by a copy to the destination pool) can now target
Linstor primary storage:

- Linstor added to the staged-conversion destination pool types, so
  destination pool discovery considers cluster- and zone-wide Linstor
  pools alongside NFS and RBD.
- The import host is validated to have access to each Linstor
  destination pool (it must be a LINSTOR satellite connected to the
  pool); the RBD qemu-copy capability check is preserved and the
  validation renamed to validateStagedImportHostSupport.
- The KVM-side converted-disk move already dispatches by pool type to
  LinstorStorageAdaptor.copyPhysicalDisk, which spawns the resource
  from the pool's resource group and qemu-img converts the qcow2 into
  the DRBD block device; converted-disk metadata for Linstor pools now
  reports the pool UUID and volume name instead of parsing NFS mounts
  (Linstor pools have no local mount path).

The imported volume keeps the copy-time UUID as its path; the Linstor
driver addresses existing volumes by path, so later volume lifecycle
operations (attach, resize, snapshot, delete) work unchanged.

Direct VDDK import into an RBD pool copied each disk, then finalized with
virt-v2v-in-place fed a domain XML whose disks were native
<disk type='network' protocol='rbd'> sources with a cephx <auth> element
referencing a libvirt secret. virt-v2v's '-i libvirtxml' input runs without a
libvirt connection, so the secret could not be resolved and libguestfs
attached no drives, failing with 'you must call guestfs_add_drive before
guestfs_launch' (observed on EL9).

Serve each RBD image over a temporary localhost qemu-nbd bridge and point the
finalization XML at the NBD endpoints instead - the same approach the CBT
cutover already uses - so no secret needs resolving. The bridges are torn
down on exit.

Copying a converted disk into a freshly created thin block-device target
(Linstor/DRBD) fully allocated the volume: qemu-img convert and nbdcopy do
not assume a block-device destination is zeroed, so they wrote out every zero
block. A 30 GiB volume holding ~2 GiB of data became 99.99% allocated on all
replicas, exhausting the thin pool.

Pass -n --target-is-zero to qemu-img convert and --destination-is-zero to
nbdcopy for pre-created block-device targets. Also fix the QemuImg
--target-is-zero capability detection: newer qemu (10.x on EL9) no longer
lists the flag in 'qemu-img --help' while still supporting it, so probe the
convert option directly - this is also why the Linstor adaptor's existing
zero-skip (copyPhysicalDisk) silently stopped engaging.

…deletes

When a CBT migration is cancelled, its initial/delta sync data-plane copy is
not aborted by the cancel itself, so it can still be writing into - and
holding open - the very target volumes the cleanup then tries to delete. The
surviving copy also keeps burning VDDK/network/storage on a dead migration.

Before deleting the marker-guarded target images/volumes, kill the in-flight
copy processes whose command line references this migration's marker (matches
the nbdcopy / qemu-img convert / qemu-io processes; the nbdkit --run parent
exits with its child), then delete with a short retry to ride out the brief
window where the device is still held open (DRBD demotion, qemu teardown).

…BT states

- importVm (VMware to KVM): validate the data-disk offering mappings right
  after the source instance is discovered, before any conversion starts. The
  same count check previously ran only at import time, after every byte of
  the source disks had already been copied and converted (~20 wasted minutes
  per attempt in lab testing), and a validation failure at that late stage
  also orphaned the already-copied direct-import volumes.

- startVmwareCbtMigration: same pre-flight against the discovered source
  disks, so a missing datadiskofferinglist fails before the initial full
  sync instead of at cutover import.

- markMigrationFailed: do not overwrite a terminal migration state - a cancel
  racing with an in-flight sync previously flipped Cancelled to Failed when
  the aborted sync's failure landed afterwards.

…py for RBD)

Two data-plane efficiency improvements for the agent's own nbdkit full-disk
copies (cold direct import and CBT initial full sync). Neither touches the
staged virt-v2v conversion path, which drives its own VDDK input.

- VDDK NBD compression: the nbdkit vddk plugin now runs with
  compression=<value> (new agent.properties key vddk.nbd.compression,
  default fastlz; none/zlib/fastlz/skipz). In extent-less setups (e.g.
  NFS-backed datastores) VDDK reports the whole disk as allocated and the
  full nominal size crosses the network; fastlz compresses both zero regions
  and real data on the ESXi side at low CPU cost. Measured on a 30 GiB disk:
  32.4 GB over the wire uncompressed vs 2.65 GB with fastlz.

- nbdcopy over qemu-nbd for RBD full copies: cold-direct-to-RBD and the CBT
  initial full sync to RBD previously used a single-stream qemu-img convert
  (RBD images are created inline by qemu-img, so they were never
  pre-created). They now pre-create the raw RBD image (qemu-img create),
  serve it over a localhost qemu-nbd bridge, and copy NBD-to-NBD with
  multi-connection nbdcopy - the same bridge approach the CBT cutover uses -
  falling back to qemu-img convert when nbdcopy is unavailable. The fresh
  image reads as zeros, so --destination-is-zero keeps it sparse. The Linstor
  block-device path already used nbdcopy directly; delta cycles are
  unchanged (a range copier is required there).

Extends the KVM unmanaged-import / manage-volume adoption path so an existing
raw Linstor (DRBD) volume can be adopted as a VM ROOT or DATA volume, mirroring
the existing RBD adoption:

- LibvirtCheckVolumeCommandWrapper: Linstor added to the supported pool types
  and routed through the raw-block-device inspection path (qemu-img on the
  /dev/drbd device) instead of checkQcow2File, which rejects a raw device.
- LibvirtGetVolumesOnStorageCommandWrapper: Linstor added to the qemu-img
  supported types (data-volume listing/adoption); it inspects the local device
  path directly, no rbd: URI.
- VolumeImportUnmanageService.SUPPORTED_STORAGE_POOL_TYPES_FOR_KVM: add Linstor
  so standalone data-volume import/unmanage accepts it.
- VolumeOrchestrator.getSupportedImageFormatForCluster: RBD or Linstor => RAW.

Unit tests mirror the RBD cases (CheckVolume via /dev/drbd device path,
VolumeOrchestrator Linstor->RAW).

The generic IS_LOCKED signal comes from a host-local qemu-img file lock, which
for Linstor/DRBD does not reflect a resource attached to a running VM on another
node (unlike RBD's cluster-wide exclusive lock). Add a
KVMStoragePool.getVolumeInUseNode() capability (default null), implemented for
Linstor via the existing LinstorUtil.isResourceInUse cluster-wide InUse query,
and OR it into the IS_LOCKED detail in both the CheckVolume (root) and
GetVolumesOnStorage (data) adoption paths, so a volume still in use anywhere in
the cluster is refused with a clear reason.